Skip to content

feat: add MiniMax as an alternative LLM provider (M3 default)#11146

Open
octo-patch wants to merge 3 commits into
stackblitz:mainfrom
octo-patch:feature/add-minimax-provider
Open

feat: add MiniMax as an alternative LLM provider (M3 default)#11146
octo-patch wants to merge 3 commits into
stackblitz:mainfrom
octo-patch:feature/add-minimax-provider

Conversation

@octo-patch
Copy link
Copy Markdown

@octo-patch octo-patch commented Mar 17, 2026 •
edited
Loading

Summary

Add MiniMax as an alternative LLM provider to bolt.new, with MiniMax-M3 as the default model. Users can switch from Anthropic (Claude) to MiniMax by setting DEFAULT_LLM_PROVIDER=minimax and MINIMAX_API_KEY in .env.local.

Changes

  • Add getMiniMaxModel to app/lib/.server/llm/model.ts using @ai-sdk/openai with the OpenAI-compatible endpoint https://api.minimax.io/v1
  • Add LLMProvider type and getModel(provider, ...) to dispatch by provider
  • Add getMiniMaxAPIKey, getLLMProvider, getProviderAPIKey helpers in app/lib/.server/llm/api-key.ts
  • Extend worker-configuration.d.ts with MINIMAX_API_KEY and DEFAULT_LLM_PROVIDER env bindings
  • Update CONTRIBUTING.md to document the new provider and how to configure it
  • Add unit tests (model.spec.ts, api-key.spec.ts) and an opt-in E2E test (minimax.e2e.spec.ts, skipped without MINIMAX_API_KEY)

Model Configuration

The MiniMax provider supports:

Model Role
MiniMax-M3 Default — 512K context, up to 128K output, image input support
MiniMax-M2.7 Previous-generation alternative
MiniMax-M2.7-highspeed Previous-generation low-latency alternative

Anthropic remains the default provider; nothing changes for existing users unless they opt in to MiniMax.

Why MiniMax-M3?

MiniMax-M3 is the latest model in the MiniMax family:

  • 512K context window
  • Up to 128K max output tokens
  • Image input support on both OpenAI-compatible and Anthropic-compatible endpoints

See pricing: https://platform.minimax.io/docs/guides/pricing-paygo

Testing

  • pnpm test — all unit tests pass (22 tests)
  • E2E test (minimax.e2e.spec.ts) verified end-to-end against the MiniMax API with MINIMAX_API_KEY set: basic chat with M3, streaming with M3, and the MiniMax-M2.7-highspeed alternative
  • Existing Anthropic flow unaffected — defaults to Claude when DEFAULT_LLM_PROVIDER is unset

feat: add MiniMax as an alternative LLM provider
46d473f 
- Add MiniMax-M2.5 and MiniMax-M2.5-highspeed model support via @ai-sdk/openai
- Introduce provider selection via DEFAULT_LLM_PROVIDER env var
- Add MINIMAX_API_KEY environment variable support
- Refactor model.ts to support multiple providers (factory pattern)
- Update stream-text.ts to conditionally apply Anthropic-specific headers
- Add unit tests for model and api-key modules (22 tests)
- Add integration tests for MiniMax API (3 E2E tests)
- Update CONTRIBUTING.md with MiniMax setup instructions
@bolt-new-by-stackblitz
Copy link
Copy Markdown

bolt-new-by-stackblitz Bot commented Mar 17, 2026

Review PR in StackBlitz Codeflow Run & review this pull request in StackBlitz Codeflow.

feat: upgrade MiniMax default model to M2.7
7f0ed47 
- Update default model from MiniMax-M2.5 to MiniMax-M2.7
- Update E2E tests to use M2.7 and M2.7-highspeed models
- Update CONTRIBUTING.md documentation
- Keep all previous models as alternatives
@octo-patch octo-patch changed the title feat: add MiniMax as an alternative LLM provider feat: add MiniMax as an alternative LLM provider (M2.7) Mar 18, 2026
feat: upgrade MiniMax default model to M3
8c03479 
- Update default model from MiniMax-M2.7 to MiniMax-M3
- Update unit tests and E2E tests to use M3
- Update CONTRIBUTING.md to document M3 as default
- Keep MiniMax-M2.7 and MiniMax-M2.7-highspeed as alternatives
@octo-patch octo-patch changed the title feat: add MiniMax as an alternative LLM provider (M2.7) feat: add MiniMax as an alternative LLM provider (M3 default) Jun 2, 2026
@ivanm696
Copy link
Copy Markdown

ivanm696 commented Jun 6, 2026

Skip to content
bolt-new-local
Repository navigation
Code
Issues
Settings
Settings: ivanm696/bolt-new-local
Access
Code and automation
Security and quality
Integrations
Rulesets
/
Protect
Active
Ruleset created
Ruleset Name
*
Protect
Enforcement status
Bypass list
Exempt roles, teams, agents, apps, and users from this ruleset by adding them to the bypass list.
MaintainRole
Always allow
Select bypass mode
Cloudflare Workers and Pages
Cloudflare Workers and PagesApp • cloudflare
Always allow
Select bypass mode
Target branches
Which branches should be matched?
Branch targeting criteria
All branches
Applies to 1 target:
main
.
Rules
Which rules should be applied?
Branch rules

Restrict creations
Only allow users with bypass permission to create matching refs.

Restrict updates
Only allow users with bypass permission to update matching refs.

Restrict deletions
Only allow users with bypass permissions to delete matching refs.

Require linear history
Prevent merge commits from being pushed to matching refs.

Require deployments to succeed
Choose which environments must be successfully deployed to before refs can be pushed into a ref that matches this rule.

Require signed commits
Commits pushed to matching refs must have verified signatures.

Require a pull request before merging
Require all commits be made to a non-target branch and submitted via a pull request before they can be merged.
Required approvals
The number of approving reviews that are required before a pull request can be merged.

Dismiss stale pull request approvals when new commits are pushed
New, reviewable commits pushed will dismiss previous pull request review approvals.

Require review from specific teams
A collection of reviewers and associated file patterns. Each reviewer has a list of file patterns which determine the files that reviewer is required to review.

Require review from Code Owners
Require an approving review in pull requests that modify files that have a designated code owner.

Require approval of the most recent reviewable push
Whether the most recent reviewable push must be approved by someone other than the person who pushed it.

Require conversation resolution before merging
All conversations on code must be resolved before a pull request can be merged.
Allowed merge methods
When merging pull requests, you can allow any combination of merge commits, squashing, or rebasing. At least one option must be enabled.

Require status checks to pass
Choose which status checks must pass before the ref is updated. When enabled, commits must first be pushed to another ref where the checks pass.

Block force pushes
Prevent users with push access from force pushing to refs.

Require code scanning results
Choose which tools must provide code scanning results before the reference is updated. When configured, code scanning must be enabled and have results for both the commit and the reference being updated.

Require code quality results
Choose which severity levels of code quality results should block pull request merges. When configured, a code quality analysis must be done on the pull request before the changes can be merged.

Automatically request Copilot code review
Request Copilot code review for new pull requests automatically if the author has access to Copilot code review and their premium requests quota has not reached the limit.
Footer
© 2026 GitHub, Inc.
Footer navigation
Terms
Privacy
Security
Status
Community
Docs
Contact
Manage cookies
Do not share my personal information
List updated, Focused item: Maintain, selected, 3 of 28

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@octo-patch @ivanm696